home *** CD-ROM | disk | FTP | other *** search
/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / misc / 40 / compile.doc next >
Encoding:
Text File  |  1986-07-17  |  4.2 KB  |  82 lines
  1. Since you have this disk (and probably have it companion), I am assuming that
  2. you are interested in compiling PC (ST) HACK.  Here is how I did it.
  3.  
  4. SYSTEM REQUIREMENTS:
  5. First, you need a C compiler (I did this with Lattice C).
  6.  
  7. You need at least the equivalent of two single sided disk drives.  I used
  8. a 1 MByte 520 ST and single sided disk drive.  For compiling, I used 512K
  9. of the memory for a RAM disk and loaded both compiler passes, the LC program
  10. that invokes the passes, the stdio.h, setjmp.h, and osbind.h into it.  Then
  11. I added the headers.fld folder from the first source disk.  If you are doing
  12. any modifications, you can also load an editor (I used the micro EMACS, about
  13. 30 KBytes).  Then, I moved the .c source files from the disk to RAM disk, four
  14. at a time, edited and compiled them.  The .bin files generated were copied
  15. onto an empty diskette.  All the files alphabetically before u_init fit on
  16. one diskette.  The command line to compile each file is:
  17.     lc -n -iheaders.fld\ <name>
  18. All the rest of the .bin files, the .lnk file, and the .ttp resulting file
  19. fit on one more diskette.  You don't need to compile all the .c files.  The
  20. one called makedefs.c is used just for generating the data file for the game.
  21. Furthermore, some are others broken into pieces that the linker can handled.
  22. These are easily identified by the main name followed by a number (i.e. do.c
  23. was broken into do1.c and do2.c.  Compile do1.c and do2.c, but not do.c).
  24.  
  25. After compiling each file, I resized the RAM disk to 400K.  Then, I copied
  26. the linker, clib.bin, startup.bin, the hack.lnk file, and all the .bin files
  27. from the second diskette onto the RAM disk.  I put the first diskette into the
  28. drive and invoked the linker with the command line:
  29.     linker -with hack -nolist -prog hack.ttp
  30. Six minutes later (if all goes well), the program is linked.  Then it
  31. can be copied to the game diskette.
  32.  
  33. PROBLEMS:
  34.  
  35. Here is a list of problems I encountered in compiling this beast (pun intended).
  36.  
  37. 1) max() is defined in a header file.  It was used as the formal parameter
  38. to a function and the compiler wouldn't take it.  Solution: change the name
  39. of the formal parameter.
  40.  
  41. 2) one function declared 7 parameters, all register variables.  The second
  42. pass of the compiler choked on this.  Solution: remove the register specifier.
  43.  
  44. 3) the compiler converted all symbols passed to the linker to upper case letters
  45. (so xmonname and Xmonname were both seen by the linker as XMONNAME).  Solution:
  46. change the name of one function.
  47.  
  48. 4) some files would not link.  The linker gave a "relocation" error.  In the
  49. process of breaking the files up to find where the problem is, I discovered
  50. that each piece would link separately.  What is ironic is that some of the
  51. largest files linked with no problem and some of the smallest failed!
  52. Solution: break up the unlinkable files and try again.
  53.  
  54. 5) some messages were incomplete.  The strncpy library routine ALWAYS places
  55. a null at the end of the string.  The standard UNIX(r) routines place a null
  56. at the end only if one is found in the source string before the specified
  57. number of bytes are copied.  Solution: write a strncpy routine.
  58.  
  59. 6) address bombs when reading and writing game files to or from the RAM disk.
  60. This one appears to be a problem in TOS that sometimes shows up when a large
  61. (more than sector number) of bytes are written after an odd number of bytes.
  62. Solution: be sure an even number of bytes are written in each write call.
  63.  
  64. 7) bus error bombs when generating and reading back "bones" files.  This one
  65. was traced to some bad code generated by the compiler.  Here is the variable
  66. declaration:
  67.  
  68.     struct permonst mons[]={...
  69.     }
  70.     struct permonst pm_ghost={...};
  71.  
  72. Later, a pointer was set to pm_ghost and &mons[0] was subtracted from it.
  73. When the result should have been 0x39, it came out as 0x60039.  The linker
  74. map showed that pm_ghost was 0x39 * sizeof(permonst) bytes away from mons[0].
  75. Solution: fold pm_ghost and similar structures into the mons array of
  76. structures.
  77.  
  78. 8) "record" file (containing the scores from previous games) gets garbage.
  79. This has been traced to the fscanf library routine (thus, the program appears
  80. to write the scores fine, but sometimes can't read what it wrote).  Solution:
  81. I haven't found one yet.
  82.